独家|微服务网关组件在金融的实践

导语

随着车金融业务的快速发展，单体架构的系统已经不能满足业务的快速发展的需要，在这种情况下，本文主要介绍微服务网关在金融的实践与演进过程。

背景

随着车金融业务的快速发展，单体架构的系统已经不能满足业务的快速发展的需要，因此在2018年初，我们对车金融业务进行了微服务架构的升级改造， 整个系统拆分出40多个微服务。在重构过程中我们发现以下几个问题：

• 每一个访问微服务系统的客户端都需要维护一份服务路由关系；
• 一些通用的如身份鉴权、权限控制等功能，微服务中重复开发。

为了解决上述的痛点，方便统一调用微服务接口，所以在架构上引入了服务网关。

什么是网关

网关又称为API网关，是微服务系统的唯一流量入口。所有的客户端都通过网关访问微服务，API网关封装了系统的内部访问，同时提供了部分通用的功能，比如：身份验证、权限、负载均衡、限流、熔断、灰度发布等。以电影场景举例来说：顾客1观看3D电影，由检票员检票通过之后发放3D眼镜，并指引顾客进入3D观影厅；顾客2和顾客3观看2D电影，由检票员检票通过之后，指引顾客进入2D观影厅；在互联网领域中，顾客为流量，检票为身份鉴权，发放3D眼镜为对请求的扩展，指引顾客进入不同的观影厅为对请求的路由。

API网关优势

在不引入网关系统的情况下：

1.客户端会请求不同的微服务，会增加客户端复杂性

2.每个服务需要独立开发相同的非业务功能（身份认证）

引入网关系统后：

1.降低客户端访问微服务的复杂度，对路由配置统一管理

2.提供公共通用功能（如：权限控制，身份认证）

技术选型业界网关解决方案有很多，包括商业的、开源的。例如Tyk（Tyk 是一个基于Go实现的网关服务）、Kong、Orange（和Kong类似，中国人开发，有比较有好的UI界面）、api-umbrella（Ruby实现的一个 API 网关）、apiaxle（Nodejs 实现的一个 网关）、Netflix zuul、nginx＋lua等；最终，由于金融的java生态，并且基于spring体系的java架构，决定技术选型为Netflix zuul作为金融的网关服务。ZUUL简介zuul是什么？zuul是API网关的开源实现方案，主要包含了对请求的路由和过滤两个功能。zuul是由Netflix开源的微服务网关，是基于JVM的路由器和服务端负载均衡器，可以和Consul、Ribbon、Hystrix等组件配合使用，并且Spring Cloud对Zuul进行了整合，使我们可以非常简洁方便的构建我们的API网关。zuul的核心是一系列的filters, 其作用可以类比Servlet框架的Filter，或者AOP；zuul中定义了四种标准过滤器类型，这些过滤器类型对应于请求的典型生命周期。1.PRE：这种过滤器在请求被路由之前调用。可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。2.ROUTING：这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用Apache HttpClient或Netfilx Ribbon请求微服务。3.POST：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTPHeader、收集统计信息和指标、将响应从微服务发送给客户端等。4.ERROR：在其他阶段发生错误时执行该过滤器。下图为过滤器的生命周期：

金融网关实践1.网关建设初期随着金融多业务线的不断发展，网关需要提供更多的功能，比如：灰度，白名单标签等。同时，不同的业务也需要搭建网关服务。所以网关面临下面三个问题：1）新接入业务必须要修改静态路由配置文件，熟悉spring的同学都知道就是yml文件，这样势必会引入线上重启的风险；2）随着服务接入的增多，各个服务也会有各种拦截功能的调整，比如首页不需要登录拦截，基础数据不需要权限功能等，这时候需要修改网关中的源码来做到这种适配；3）伴随着金融各个业务线微服务架构调整，每个业务线都需要建设自己的网关，各个业务线的网关有许多相同的功能相互重叠，并且得不到复用，每个业务线也需要投入人力去开发与维护相关的工作；基于上面的三个问题，我们对金融网关也进行了改造升级。2.网关云演进过程

为了改造原有各个业务线重复建设导致的资源浪费，首先整合所有业务网关到单集群中，然后依托于集团云平台的流量分组能力，在网关内部对不同业务线做了流量隔离。引入数据库作为网关配置，把服务注册、路由配置以及功能组件作为动态配置项，提供可视化界面增加、修改配置信息，配置的修改会通过消息队列通知网关集群，网关修改相应的内部配置缓存；以此来支持网关功能组件的可插拔式配置；目前网关的内部架构可以灵活的支持不同业务线的业务拦截需求，对内部新业务的扩展也可以做到通过配置的形式支持。下面将详细介绍网关功能组件的动态配置及动态路由的改造过程。

（1）网关动态配置演进

网关对于不同的请求做不同的功能拦截操作，需要修改相关代码做一些适配工作。随着网关集群的业务线增加，每个业务线都需要一些需求调整，这时候会带来一些网关功能的调整，为了节省修改代码的人力成本和消除不必要的上线；因此，我们就思考如何才能把这些静态配置化操作转为动态化呢？

为了做动态化拦截功能配置。首先把拦截功能模块基于责任链模式做了拆分，拼接链的环节通过配置中心加载到内存中的配置，对不同的服务进行不同的责任链拼接，这样配置中心修改配置网关实时感知配置的变动，进行动态拦截功能模块的动态配置化改造。那么对于动态路由的改造呢？

（2）动态路由

由于zuul在不引入注册中心的情况下只支持通过yml、properties获取路由信息，对于接入新服务非常的不友好，因为要修改静态配置文件然后进行上线升级操作。在第一版的演进过程中希望通过db暂时作为配置中心，而不引入注册中心。因此通过对相关的源码进行了查看（本文内相关源码及配置均有删减，代码出处见参考文献）

@Overridepublic void service(javax.servlet.ServletRequest servletRequest, javax.servlet.ServletResponse servletResponse) throws ServletException, IOException {            ...            // 路由预处理(pre阶段)            preRoute();            ...            // 路由阶段(route阶段)            route();            ...            // 请求响应阶段(post阶段)            postRoute();}在路由阶段（route阶段）请求会先经过RibbonRoutingFilter，然后经过SimpleHostRoutingFilter以下代码分别是两个filter的执行条件

//RibbonRoutingFilterctx.getRouteHost() == null && ctx.get(SERVICE_ID_KEY) != null&& ctx.sendZuulResponse());
// SimpleHostRoutingFilterRequestContext.getCurrentContext().getRouteHost() != null && RequestContext.getCurrentContext().sendZuulResponse();

通过以上代码，结合application.yml配置文件

zuul:    routes:        service1:          path: /service1/**          url: http://127.0.0.1:8080        service2: path: /service2/**          serviceId: service2

当调用到RibbonRoutingFilter时会去判断serviceId是否为空（执行路由条件），当调用到SimpleHostRoutingFilter时会校验host是否为空。

由此推断路由信息是在pre阶段确定下来的，然后定位到PreDecorationFilter会根据请求URI匹配相应的路由信息，然后获取静态配置中的路由信息解析出相应的RouteHost和serviceId。其源码（由于源码过长，请同学们自行查看）中RouteLocator即为我们的路由定位器，也就是我们要重写的部分。

（3） 路由定位器

PreDecorationFilter通过RouteLocator根据URI获取Route，因此可以通过对RouteLocator的扩展来完成动态路由工作。Spring Cloud默认的路由定位器由SimpleRouteLocator来实现。

主要功能包含：

• 通过properties获取所有路由；

• 根据请求URI获取路由信息；

代码如下：

public class SimpleRouteLocator implementsRouteLocator, Ordered {
// routes 用于存储路由信息 private AtomicReference<Map<String,ZuulRoute>> routes = new AtomicReference<>();
// 查找路由信息      protected Map<String, ZuulRoute> locateRoutes() {  LinkedHashMap<String, ZuulRoute>routesMap = new LinkedHashMap<>();  // 提取ZuulProperties中的ZuulRoute for (ZuulRoute route :this.properties.getRoutes().values()) {     routesMap.put(route.getPath(), route); }       return routesMap; }
// 根据请求匹配路由 protected Route getSimpleMatchingRoute(final Stringpath) { // 确认初始化路由map完成 getRoutesMap();
// 对URI处理            String adjustedPath = adjustPath(path); // 获取匹配路由 ZuulRoute route = getZuulRoute(adjustedPath); return getRoute(route, adjustedPath);      }}

所以这里继承SimpleRouteLocator并重写了locateRoutes函数，由properties获取路由信息改为通过DB获取我们的路由信息。 

@Overridepublic Map<String, ZuulRoute>loadLocateRoute() { List<ZuulRouteDto> zuulRouteDtos =getZuulRoutes(); // 把DB获取的路由信息转为Map Map<String, ZuulRoute> handle =handle(zuulRouteDtos); return handle;}
/*** @authorpenghb* @description 获取所有路由* @date 8:37PM 2019/6/3* @return 路由列表**/private List<ZuulRouteDto> getZuulRoutes() { String cloudClusterGroup =System.getenv(SYSTEM_CLOUD_GROUP); APIResponse<List<ZuulRouteDto>> all = zuulRouteService.findByCloudGroupCode(cloudClusterGroup); return APIResponseUtils.getResultData(all);}

（4） 路由动态刷新

由于Spring Cloud默认的SimpleRouteLocator是不支持路由刷新的，但是自定义的动态路由是要支持路由的刷新功能的（当配置中心路由信息修改后，网关要实时的刷新路由信息），因此在继承SimpleRouteLocator的基础上，还要实现Zuul提供的RefreshableRouteLocator来支持动态路由刷新能力。

zuul内部提供了ZuulRefreshListener，它会监听ApplicationEventPublisher发布的事件，如果事件为RoutesRefreshedEvent，则会调用routeLocator的refresh函数，在自定义的路由定位器中可以直接调用SimpleRouteLocator的doRefresh函数：

protected void doRefresh() { this.routes.set(locateRoutes());}当路由信息在配置中心发生变化的时候，就通过ApplicationEventPublisher发布一个RoutesRefreshedEvent事件：

RoutesRefreshedEventroutesRefreshedEvent = new RoutesRefreshedEvent(routeLocator);publisher.publishEvent(routesRefreshedEvent);

这样动态刷新路由也实现了。

最后向IOC容器中注入自定义的路由定位器，去替换Spring Cloud的路由定位器。

@Bean@ConditionalOnMissingBean(ZuulRouteDatabaseLocator.class)public ZuulRouteDatabaseLocator zuulRouteDatabaseLocator() {      return newZuulRouteDatabaseLocator(this.server.getServletPrefix(), this.zuulProperties);}

这样完整的动态路由就实现完成了。

引入consul作为注册中心经过上面的改造后，发现在应用过程中新接入服务必须要经过人工配置，并且新服务都需要为接入网关而申请内网域名，为了解决人工配置和申请域名的人工介入，注册中心就粉墨登场了。Consul是一种服务网络解决方案，可跨任何运行时平台以及公共或私有云连接和保护服务。金融网关借助于集团的云平台，在每一个业务实例所在的docker中，启动一个consul的agent进程（即consul client），这个agent会收集业务实例进程的相关信息（如：容器ip、业务进程端口等）上报给consul server集群，该agent也负责做服务的健康检查相关的工作，并且随服务一起启动，一起销毁；然后网关会通过consulserver获取服务路由信息进行路由。通过引入consul彻底解决了服务的人工配置，做到了自动化的服务发现与路由。网关内部线程模型目前我们使用的zuul版本为1.x，该版本中对一次请求的拦截与路由使用的是同步阻塞线程；1.优势首先在设计层面上架构设计简单，其次源码阅读上代码易于理解，最后是链路追踪比较方便，出现问题时易于排查。2.  缺点zuul内部本质上是一个同步的servlet，这样每一个请求servlet都会为其分配一个线程来处理这个请求，但是容器中的线程是有限的，一般会使用线程池，当后端服务响应缓慢时，线程资源会被持续占用，当线程被大量占用导致连接池满之后，新请求会被拒绝。未来展望对于网关目前存在的问题，首先在未来会基于Netty去改造金融网关；同时网关也是所有服务的入口，也会对服务的性能分析以及健康指标做一些相关的分析工作。
参考文献： 1.zuul github（https://github.com/Netflix/zuul/wiki）2.zuul源码（https://github.com/Netflix/zuul/tree/1.x）
作者简介：彭海滨，金融公司车贷技术部开发工程师，负责金融公司网关建设和开发。

END

相关推荐：独家|Linux进程内存用量分析之堆内存篇
独家| rocksdb compaction限速实践与源码分析
独家|一文了解58安全画像系统演进之路